敏捷测试的成熟度评估

读完需要

8分钟

速读仅需 3 分钟

【最近被较多朋友问到关于敏捷测试的成熟度如何度量的问题，在此把我的一篇相关旧文转发一下。】

---

在经历了“七年之痒”后，蓝鲸项目进入第八个年头，项目的一切趋于稳定。团队倡导持续改进，可大家的感觉是已经尽力做到最好，这个时候似乎没有什么可以改进的了。为了突破这个局面，项目重新聚焦测试，从质量和测试的角度对现状进行了一次评估。

评估采用的是基于软件测试原则的模型，本文就是跟大家分享一下这个模型。

测试原则

2012 年澳大利亚敏捷大会（Agile Australia）上 ThoughtWorks 的非常资深的测试实践带头人 Kristan Vingrys 分享了如上测试原则，这些原则是 ThoughtWorks 的同事们在多年软件测试经验基础上总结出来的。

1. 质量内建（Build quality in）

You cannot inspect quality into the product; it is already there. -- W.Edwards Deming

著名的质量管理专家戴明指出：产品质量不是检测出来的，从产品生产出来后质量就已经在那了。这同样适用于软件产品。

缺陷发现的越晚，修复的成本就越高。质量内建要求我们做好软件开发每个环节，尽早预防缺陷产生，以降低缺陷出现后的修复成本，要减少对创可贴式的补丁（hotfix）的依赖。

推荐实践： TDD、ATDD 等

2. 快速反馈（Fast feedback）

每个环节的任何变化都能最快的反馈给需要的人，从而可以基于当下最新信息做出明智的决定，降低风险。这要求我们对系统进行频繁的测试，缩短回归测试的周期。

推荐实践：

• 符合测试金字塔结构的自动化测试，让每一层的测试都能发挥尽可能大的价值，给出最快速的反馈；

• 持续集成，尽早排查集成引起的问题，降低集成所带来的风险。

3. 全员参与（Involve everyone）

-- 这次上线好多 bug，QA 是怎么测的？！-- 那个 xxx 组在上线前发现了很多的 bug，他们的 QA 真给力！

成也 QA，败也 QA…如果还是这样的认识，那是极为片面的。测试不仅仅是 QA 的事情，团队成员要一起为质量负责，软件开发生命周期的测试相关活动需要全员的参与。

全员参与的好处是利用不同角色的不同领域知识和不同的思维模式，不仅可以使得测试的质量更高，同时还能最优化利用测试资源，做到价值最大化。

推荐实践：

• 自动化测试：QA 和 BA 结对用 DSL 编写测试用例，QA 和 Dev 结对编码实现测试，生成业务人员可读的测试报告；

• Bug bash（bug 大扫除）：团队不同角色一起参与的一个找 bug 的测试活动

4. 测试作为资产（Tests as asset）

自动化测试帮助我们验证系统功能的正确性，好的自动化测试还有文档的功能，是宝贵的资产。如果每个项目都构建自己独立的自动化测试，没有跨项目共享，其浪费显而易见。

这个原则要求把自动化测试的代码跟产品开发的代码一起，当做资产管理起来，在不同项目间做到尽可能的复用。这笔宝贵的资产能帮助我们更好的统计跨项目的测试覆盖率，更好的优化测试。

推荐实践：利用版本控制管理工具把测试代码和产品构建代码一起管理，都作为产品的一部分。

5. 更快的交付（Faster delivery into production）

任何一个 idea 越快做成软件产品交付给用户，给企业带来的价值越大。

该原则要求我们把测试活动融入软件开发生命周期的每个环节，不要在后期进行长时间的集中测试；同时测试人员的关注点不再是发现更多的 bug 以阻止不符合质量要求的产品上线，而是把目标放在如何能够帮助团队尽快的让产品上线，让企业投资回报更早，也就是更快的赚钱。

推荐实践：自动化构建流水线、关注平均恢复时间、发布与部署解耦等。

6. 清晰一致的测试视图（Clear and consistent view of testing）

可视化的报告给客户和内部团队展示测试的状态和产品内外部的质量，对项目的质量和风险把控是非常有帮助的。不同项目各自采用五花八门的图表样式，将不利于项目间的信息共享和比较，无端增加复杂性，带来浪费。

因此，我们需要把状态报告做的尽可能简单、清晰，并且保持跨项目的指标一致性；同时，我们不应该为了让某个指标变得好看而改变我们的行为，整个报告要诚实开放，这样才能真实反映出项目的状况。

7. 优化业务价值（Optimize business value）

开发软件无疑是要给客户的业务带来价值，软件测试也需要为这个目标服务，测试要跟业务价值保持一致，帮助客户优化业务价值。要求做到：

• 测试不仅是保险，不仅是保证软件质量的；

• 要有目的的关注变化的特性，不要盲目的散弹枪式的对任何特性进行测试，要有优先级；

• 要能帮助企业驱动新的特性和功能；

• 帮助客户创造安全的尝试新点子的环境，提供快速的反馈。

推荐实践：

• 基于风险的测试，根据业务优先级需要调整测试策略，在测试过程中尽可能规避给业务带来的风险；

• 生产环境下的 QA，通过收集生产环境的真实用户行为和应用使用数据，对业务的优化做出贡献。

评估模型以及在项目中的应用

评估模型就是将上述七条原则的每一条细化，列出该原则对应的实践和行为，并给每个实践或行为设定 0-5 分的不同评分标准，最后统计各个原则的总分，形成类似下图的结果报告：

在项目中的应用

以 Kristan 分享的模型为基础，由 Tech Lead 和几个 DEV、QA 成立一个评估小组。

第一步：分别根据各自的理解给项目打分，结果是很有意思的，请看下图：

根据这些结果，可以看出大家的认识是不太一致的。

第二步：评估小组对模型中的每条细节进行 review，做适当修改以更符合项目情况，并且在评估小组内大家达成共识。其中，所做的修改包括修改原有的实践评分指标、增加新的更适合项目和当前技术趋势的实践、删除过时的或者不符合项目特点的实践。

第三步：根据更新过后的模型指标对项目上的一个 Team 做评估试点，详细分析该 team 对应到测试原则各个维度的 well 和 less well 部分，由评估小组成员一起打分，得到该 team 的评估结果图。

第四步：根据评估结果并结合项目目标排定需要改进的优先级，制定出改进 action，并更新给试点 team 执行。

后续：试点一个周期后再次评估，并重新 review 评估模型，再推行到整个项目。同时，周期性的进行新的评估和制定新的 action，以做到持续的改进和优化。

总结

应用程序的质量、测试的快速性、以及上线后轻松自信的更新服务的能力，是帮助企业业务价值最大化的关键因素之一，一直是我们所追求的。

基于测试原则的评估模型，可以帮助我们在追求这个目标的道路上少走弯路，帮助我们持续的改进，以驱动出更加卓越的软件。